Web services are increasingly viewed as an important component in building distributed applications. As these services inevitably evolve and change, service version management will increasingly become a key part of the service lifecycle. In this context the lack of an end-to-end versioning model provides challenges to the service provider when trying to manage version transitions, especially in a continuous availability context, especially in the web services model of once published, always published. Versioning of web services is challenging, because it inevitably affects each part of the service lifecycle.
A common scenario is the rollout of a new version which is backward compatible with a previous version. Compatible version transition should ideally be handled in such a way that existing service consumers are insulated from any knowledge of the change. In a continuous availability context, the service provider ideally wants to manage this type of version transition smoothly in such a way that there is no service disruption. Ideally, a new version is appropriately tested in the production environment before committing to the transition. The transition is rolled out gradually (at whatever rate is appropriate) and with a way to smoothly back out or rollback problem versions. In order to support these types of transitions it is necessary to support concurrent deployment of multiple service versions. If two or more compatible versions of a service are deployed concurrently, the problem of how to route service requests to an appropriate version must be explicitly addressed.
The known art in supporting versioning of web services falls into two approaches. One focuses on methods of dealing with and or simplifying the problem of adaptation by the service consumer to service changes, i.e. requiring the active participation of the service consumer to cooperate with service provider changes. For a backward compatible change another approach is to address the version transition aspect with for example, an orchestration scheme to manage the transition as quickly as possible without any service disruption. This insulates the service consumer from any awareness of the change with the constraint being that only one version of the service can be active at a time.
The web services versioning problem is a subset of the second approach, the more general distributed programming model. A distributed programming model service, such as a web service, consists of a service implementation which performs some function (an implementation module), a service specification which describes the function and how the service can be invoked (such as a WSDL file), and service requestors which make service requests of the service provider following the service specification (such as a web service client). We use the more general term service in the following discussion with the understanding that it is applicable to a web services model as well as other distributed service models.
Versioning is an often overloaded term, which can have different meanings depending on the context or the viewpoint. From the service consumer's point of view, a web service “version” would describe and apply to the interface of the service—the operations and parameters, results, etc. of this particular version. A service provider, hosting multiple versions of a service, manages implementation versions which need to be installed, started, stopped, and so on. These two versioning concepts, while inter-related, are not the same.
During a service's lifetime, it will usually go through one or more revisions as requirements or business needs change. When a new version of a service is ready to be deployed, the service provider necessarily needs to plan for the upgrade. In selecting a version transition strategy, the service provider is faced with the task of introducing the new version in such a way so as to provide a smooth, managed transition, with support to back out a problem version, while maintaining continuous availability and minimizing the impact on service consumers.
One strategy which provides a smoother and more flexible (compatible) version transition is to support the side-by-side deployment of two versions. During a phased transition period, both versions can operate simultaneously until such a time as the system administrator is confident and ready to retire the old version. In practice, these transition periods can be arbitrarily long, especially with stateful services or long running business processes which have instantiated data associated with a particular version of the service.
In an unversioned environment, a common approach is usually limited to swapping the old version with a backward compatible new version. Without support for multiple version coexistence, some sort of rollout orchestration is used to handle the changeover as quickly as possible while maintaining continuous availability. This type of in place exchange, while transparent to the service consumer, provides little flexibility to the service provider. To get around the version coexistence limitation, the service provider can deploy a new version with a new name which, while giving more flexibility, has the unattractive quality of requiring the explicit cooperation of service consumers to adjust to the version change.